[Dies ist ein Fallbeispiel, das in einem separaten Fenster angezeigt wird. So können Sie das Beispiel und ein beliebiges anderes Hilfethema gleichzeitig betrachten. Das Fenster des Fallbeispiels lässt sich verschieben, in seiner Grösse ändern und über das Schliessfeld verlassen]
Die Wahl einer komplexeren Datenstruktur führt oft zu einfacheren Zugriffsoperationen. Wir veranschaulichen diese Faustregel an der Eingabe von Testterminen.
Ein erstes Beispiel einer Eingabeprüfung finden Sie auf dem Stammformular FrmAllgemeines. Sein Unterformular Testtermine nimmt alle Tests auf, zu denen die laufende Aufgabe gehört:
Die Autorin wählt einen Testtermin, indem Sie auf auf den Abwärtspfeil des Kombinationsfelds Nr. klickt. Nach dem Klick kann sie aus einem Menü eine der folgenden Zeilen auswählen:
Die Autorin ist gezwungen, einen vollständigen Testtermin zu wählen. Die Komponenten Veranstaltung, Semester und Jahr kann sie nicht einzeln kombinieren. Dieser Interaktion liegt der folgende Ausschnitt des Datenbankstrukturdiagramms von Testverwaltung.mdb zugrunde:
Jede Zeile der Tabelle FRAGEN ist über das Verbundattribut Fragenschlüssel mit n Zeilen der Tabelle FRAGENVERWENDUNG verbunden. Die Tabelle FRAGENVERWENDUNG ist ihrerseits über das Verbundattribut Testschlüssel mit der Nachschlagetabelle TESTS verbunden. In diese Nachschlagetabelle trägt die Autorin jeden möglichen Testtermin ein einziges Mal ein und wählt jedesmal, wenn sie eine Aufgabe einem Testtermin zuordnet, einen dieser Termine. Eingabefehler können somit nur in der (selten benutzten) Nachschlagetabelle TESTS auftreten.
Das folgende Datenbankstrukturdiagramm ist einfacher als das obige:
Ein bestimmter Test wird nicht mehr durch einen künstlichen Testschlüssel identifiziert, sondern durch den natürlichen (zusammengesetzten) Testschlüssel aus Veranstaltung, Semester und Jahr. Diese Datenstruktur ist zwar einfacher, führt aber zur redundanten Speicherung von Termintripeln (Veranstaltung/Semester/Jahr) und erschwert die Dateneingabe. Das folgende Eingabeformular zwingt die Autorin - anders als in der ersten Alternative - jedes Terminattribut einzeln einzugeben:
Dadurch werden Eingabefehler wahrscheinlicher. Die Autorin kann unerlaubte Kombinationen der Terminattribute Veranstaltung, Semester und Jahr eingeben. Eine naheliegende Implementation einer Eingabeprüfung entnimmt die erlaubten Kombinationen aus der folgenden Nachschlagetabelle VERANSTALTUNG:
Jede Termineingabe muss den folgenden Einschränkungen genügen:
Der Veranstaltungsname muss aus der Nachschlagetabelle VERANSTALTUNG stammen.
Das Eingabefeld 'Semester oder Quiz' enthält nur Werte, die zur eingegebenen Veranstaltung passen. Ein Test in 'Datenverarbeitung' darf zum Beispiel gemäss der Nachschlagetabelle nur Ende Sommersemester stattfinden.
Das Jahr ist grösser oder gleich dem entsprechenden abJahr-Wert und kleiner oder gleich dem bisJahr-Wert.
Die erste Einschränkung lässt sich wie folgt implementieren: Die Eigenschaft Datensatzherkunft des Kombinationsfeldes KmfVeranstaltung enthält eine SQL-Abfrage, die alle möglichen Veranstaltungsnamen ergibt, und die Eigenschaft Nur Listeneinträge stellt sicher, dass der Benutzer keinen anderen Namen eingeben kann:
Vor einer Validitätsprüfung der restlichen Einschränkungen setzen wir voraus, dass die Benutzerin bereits eine Veranstaltung eingegeben hat. Die Ereignisprozedur KmfJahr_GotFocus() ändert die Eigenschaften Herkunftstyp und Datensatzherkunft des Kombinationsfeldes, sobald der Eintrag des ersten Kombinationsfelds ('Getestete Veranstaltung') bekannt ist. Während diese Eigenschaften für das erste Kombinationsfeld bereits zur Entwurfszeit bekannt sind (siehe obige Abbildung), können sie für die Felder 'Semester oder Quiz' und 'Jahr' erst zur Laufzeit des Programms eingetragen werden. Die Ereignisprozedur KmfJahr_GotFocus() tut dies für das Kombinationsfeld KmfJahr. Den Code zu KmfSemester finden Sie im Formular Form_SubfrmFragenverwendung. Die Prozedur wird durch das Ereignis GotFocus (dt. bei Fokuserhalt) ausgelöst. Ein Steuerelement erhält den Fokus, bevor es eine Eingabe empfangen kann (zum Beispiel nach einem Klick auf das Steuerelement). Der folgende Entwurfscode fasst die Ereignisprozedur KmfJahr_GotFocus() zusammen:
Falls Testtermin nicht in der Reihenfolge Veranstaltung/Semester/Jahr eingegeben wird dann erinnere an die richtige Reihenfolge und gehe auf das richtige Eingabefeld sonst beschränke das Auswahlangebot von KmfJahr so, dass es den obigen Einschränkungen genügt
Die VBA-Implementation verweist die Benutzerin im If-Zweig auf das richtige Eingabefeld. Andernfalls stellt im Else-Zweig die SQL-Abfrage zusammen, die in KmfJahr die möglichen Testjahre zur Auswahl anbietet.
Private Sub KmfJahr_GotFocus() Dim SQLBefehl As String '-- Eingabereihenfolge erzwingen If IsNull([KmfVeranstaltung]) And IsNull([KmfSemester]) Then MsgBox "Bitte zuerst Veranstaltung und Semester einfügen", , "" DoCmd.GoToControl "KmfVeranstaltung" ElseIf IsNull([KmfSemester]) Then MsgBox "Bitte zuerst Semester einfügen", , "" DoCmd.GoToControl "KmfSemester" Else ' Herkunftstyp (RowSourceType) für eine SQL-Abfrage [KmfJahr].RowSourceType = "Table/Query" '-- Datensatzherkunft (RowSource) ist eine SQL-Abfrage auf VERANSTALTUNG SQLBefehl = "SELECT JAHR.Jahr " _ & "FROM Veranstaltung, Jahr " _ & "WHERE (((JAHR.Jahr)>=[abJahr] And (JAHR.Jahr)<=[bisJahr]) AND " & "((VERANSTALTUNG.Veranstaltung)='" & [KmfVeranstaltung] & "') AND " _ & "((VERANSTALTUNG.Semester)='" & [KmfSemester] & "'))" [KmfJahr].RowSource = SQLBefehl End If End Sub
Die zweite Variante der Eingabeprüfung ist trotz der einfacheren Datenstruktur schwieriger zu implementieren als die implizite Validitätsprüfung der ersten Variante.